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Abstract. Non-determinism is of great importance in functional logic 
programming. It provides expressiveness and efficiency to functional logic 
computations. In this paper we describe an implementation of the multi- 
paradigm functional logic language Curry. The evaluation strategy em- 
ployed by the implementation is based on definitional trees and needed 
narrowing for deterministic operations, while non-deterministic oper- 
ations will depend on the graph transformation, bubbling. Bubbling 
preserves the completeness of non-deterministic operations and avoids 
unnecessary large-scale reconstruction of expressions done by other ap- 
proaches. 

1 Introduction 

Non-determinism T is of great importance to functional logic computations. 
Functional logic programs using non-determinism can be more expressive than 
functional programs. Non-determinism allow computations to possibly yield more 
than one value. 

Functional logic programming |9I12I19| is a multi-paradigm programming 
that combines in a seamless way the best features of functional programming 
and logic programming. Functional programming is based on A-calculus and pro- 
vides the users with features like demand driven evaluation, polymorphic typing 
and higher-order functions. Logic programming is based on Horn clause logic, 
a subset of first order logic. Logic programming provides reasoning with partial 
data and missing information, non-determinism, logical variables, and function 
inversion. Therefore, functional logic languages have several advantages over 
functional and logic programming. Functional logic languages are more expres- 
sive than functional languages thanks to non-determinism, logical variables, and 
the ability to deal with infinite data structures. Functional logic languages are 
more efficient than logic languages because of demand-driven evaluation. 

Current implementations of functional logic languages belong to one of three 
categories: (1) Implementations that include the logic programming features in 
a functional language. (2) Implementations that extend logic languages with 
functional programming features. (3) Implementations of virtual machines that 
implement the features of logic programming and functional programming using 
an imperative language. Interested readers are referred to |19l9j for a survey of 
such languages and their implementations. 



In this paper, we present a design for an implementation of a virtual machine 
for the functional logic language Curry 18j, a community-agreed standard lan- 
guage. The implementation will focus on issues concerning non-determinism and 
logical variables that other implementations, we believe, do not tackle correctly. 
Bubbling |5I6| is a graph transformation that correctly tackles such concerns. 

In section[2]we briefly review some concepts of functional logic programming. 
In section [3] we will discuss the key concepts of bubbling in details. In section |4] 
we will describe the current implementation. In section [5] we discuss future work 
and conclude in section |6l 

2 Background 
2.1 Preliminaries 

Functional logic programs can be modeled as a class of constructor-based con- 
ditional term graph rewriting systems (TGRS). Terms are modeled as graphs to 
allow sharing of sub-terms. 

We recall the definition of term rewriting systems from |llj . 

A rewrite system is a pair, TZ= {S, R), where 17 is a signature and R is a set 
of rewrite rules. The signature E consists of different symbols where each sym- 
bol is associated with an arity and an operator designation. The main operator 
designations are constructors and defined operations. Constructors, C, are spe- 
cific operators that are used to construct data, whereas, defined operations, T>, 
operate on data to transform it into a constructor term. Numbers and list con- 
structors, such as "cons" and "nil", are examples of constructors, while multipli- 
cation "x" and division "/" are examples of defined operations. Constructors 
with no arguments (0-ary) are usually referred to as constants. Variables are 
present in functional logic programming and have a different meaning from their 
counterparts in imperative programming. Variables in functional logic program- 
ming can be assigned a value at most once in the whole execution and have no 
arguments. Variables belong to the countably infinite set X . The set of terms, 
T{E, X), is defined inductively as follows: (1) All variables x C T{E, X). (2) 
For all f e 17 of arity n > and ti, . . ., i„ € T(i:, X), i(ti, . . ., i„) e T(i:, X). 
A term, i{t\, t2, . . ., tn), is called constructor-rooted or operation-rooted if the 
operator f is a constructor or defined operation, respectively. A term, f(ii, t2, 
. . ., tn), is called a pattern if the operator f is a defined operation and ti, t2, ■ . ., 
tn are constructor-rooted terms. Variables and constructor-rooted terms repre- 
sent values commonly known as head normal form. Var(t) refers to the set of 
variables in the term t. A term t is said to be linear if each variable appears in it 
at most once. A term t is said to be ground if Var{t) = 0. Access to sub-terms is 
done through the operator | followed by a (possibly empty) sequence of natural 
numbers. For example, in the term i{ti, t2, . ■ ■, tn), access to the sub-term tp 
for 1 < p < n is denoted by i{ti, t2, ■ . ■, tn)\p. The access to the root is done 
through f(ti, t2, . . ., tn)\e- The replacement of a sub-term in term t at position 
p, t\p, with another term s is denoted by t[s]p. For example, f(ti, t2, . . ., tn)[s]|2 
corresponds to the term f(ii, s, . . ., 



Rewrite rules, R, are of the form 1 = r where 1 and r are terms; we refer to 1 
(r) as the left-hand-side (right-hand-side) of the rule. A rewrite system TZ is of 
type left-linear if all the left-hand-sides of the rules are linear. TZ is said to be 
constructor-based if all left-hand-sides of the rules are patterns. 

A substitution is a mapping a : A"— > T{S, X) that maps variables to terms. 
The application of a to variables in a term t, cr(t), replaces the variables that 
appear in t with their value in a. Two terms t and s are unified if there exists 
a substitution a such that a{t) = u{s). A rewriting step t ~^p_R s is done when 
there exists a position p in term t, a rewrite rule 1 = r in R and a substitution 
(7 such that t\p = cr(l), and s = t[cr(r)]p. A term t is said to be irreducible or in 
normal form if t cannot be rewritten to any other term using the rules in R. 

We will use graphs to represent terms. Each graph consists of a set of nodes 
and edges connecting these nodes. The nodes are labeled with an operator des- 
ignation or a variable. In the following, we extend the definition of term graphs 
with a single root, commonly known as expressions, from T¥ with some nominal 
changes. Let S he a signature, X a countable set of variables, and N a countable 
set of nodes. 

A rooted graph over < S, N, X> is a 4-tuple GRAPH g = {Ng, Lg, Eg, 
Rootg) such that: 

1. A^g C N is the set of nodes of g. 

2. Lg-. Ng — >■ E\JX is the labeling function that maps each node of g to a 
signature symbol or a variable. 

3. Eg-. Ng — )• Nat — Ng is the edge function mapping each node of g to the 
node that represent its sub-expressions. For a node n in g where Lg(u) = s, s 
G UUX , and arity(s) = k then Eg{n, 1) = ni ,. . ., Eg (n, k) = n^,, rii, . . . , 

eNg. 

4. Rootg E Ng is a node in g that is called the root of g. 

5. Every variable in the graph g labels one and only one node. That is, if Lg{ni) 
e X and Lg{n2) G X, then Lg(ni) = Lg{n2) =^ ni = n2- 

6. Each node in g is either Rootg or reachable from Rootg through the edge 
function Eg. 

(3 + 4) - 5 (1) 




Fig. 1. Pictorial representation for the expression in equation [T] 



Figure [T] is a pictorial representation of the expression in equation [T] The 
symbols The labels of the nodes, Lg, represent the symbol of the node. The 
root of the expression is the node with the name "Root" . The edge function is 
represented by the arrows that connect the nodes. 

A term rewrite system specifies the rewrite rules but does not specify the 
precedence of rules over each other. Also it does not specify which arguments 
must be evaluated and in which order. All these details are left for an evaluation 
strategy that controls and guides the rewriting process. Antoy introduced in [2] 
a hierarchy, the definitional trees, to order all the rewrite rules and to specify 
which arguments should be selected. A definitional tree for a defined operation f 
is a set of linear patterns partially ordered by subsumption. The leaves of the tree 
are variants of the left-hand sides of the rules defining f. The root is a pattern 
of the form f(A'i, . . . , X„) where Xi, . . . ,X„ are distinct variables. The inner 
nodes have an inductive position, where the children of such inner node will 
have different constructor terms. 

The following are the rewrite rules that define the operation less than or equal 
"<" [2] using Peano numbers and boolean values. Note that "_" represents an 
anonymous variable. An anonymous variable does not require any computation 
for its value. 

< _ = true 
s(_) < = false 
s(X) < s(Y) = X < Y 



|Xl|<X2 




s(X3)<0 = false s(X3) < s(X4) = X3 < X4 

Fig. 2. Pictorial representation of the definitinal tree for the defined operation 
< appearing in equation [2] The framed variables represent the position needing 
evaluation. 



Figure [2] is a definitional tree for the operation <, where the inductive posi- 
tions are surrounded by a box. The root of the tree has two variables XI and X2. 
The children of the root differ in the instantiation of the variable XI. When XI 
is instantiated to 0, X2 does not need further evaluation and the expression will 
be rewritten to true. When XI is instantiated to s(X3), the tree will instantiate 
X2 to either or s(X4). In the first case, the expression will be evaluated to 
false, while the later will require a re-application of the first rule (root) with 
the fresh variables X3 and X4. Fresh variables are variables that never appeared 
before. For more details about definitional trees, please refer to [2]. 



(2) 



2.2 Non-determinism 



Non-deterministic operations and logical variables |17I8| play an important 
role in functional logic programming. Non-determinism increases the expressive- 
ness of functional logic programs. 

The choice operator, "?", is used to express non-determinism. Any defined 
operation that is rewritten to an expression that uses a choice operator is con- 
sidered a non-deterministic operation. 

■ y " (3) 

X ? y = y ^ ^ 

Rules in equation ([s]) define the choice operator used in a rewrite rule. One 
of the arguments of the choice will be chosen non-deterministically to rewrite 
the left-hand-side of the rule. 

We recall two classes of constructor-based term rewriting systems relevant 
to our paper, inductively sequential and overlapping inductively sequential 
classes. The inductively sequential class (IS) represents the rules that constitute 
the first-order component of any functional language, and hence functional logic 
languages as well. A defined operation / is called inductively sequential if there 
is a definitional tree of / that contain all and the only rules defining /. A TRS 
is of type inductively sequential if all its defined operations are inductively 
sequential operations. The overlapping inductively sequential class (OIS) is a 
super class of the IS class. The OIS class adds non-deterministic rules to the set 
of rules that are inductively sequential. The term rewriting system class that 
will be used to model functional logic programs in this implementation is the 
OIS class [4]. 

Modeling functional logic programs in the OIS class is not a limitation as 
shown in [3]. Antoy introduced a set of transformations that will convert a 
constructor-based conditional TRS into one of its sub-classes, the overlapping 
inductively sequential TRS. We will show in section [3] an efficient evaluation 
strategy to evaluate programs modeled by the OIS class. 

The presence of variables in expressions represent that: (1) An expression is 
shared between two or more expressions. (2) A logical variable. Logical variables 
express non-determinism. Antoy et al. introduced in [5] a transformation that 
ehminates logical variables by replacing the logical variables with overlapping 
rules. 

(l+X)+(X+2) where X = (0 ? 1) (4) 



The expression in equation [4] represents sharing. Sharing is introduced in 
expressions through the use of the "where" clause. If two or more expressions 
require the evaluation of a shared sub-expression, then the shared sub-expression 
will be evaluated only once. If the shared sub-expression is duplicated, then the 
evaluation of the shared sub-expression will be done more than once. In the case 
that the shared sub-expression is a deterministic operation, the multiple evalua- 
tions will not affect the outcome of the computation, but will affect its efficiency. 




Fig. 3. Pictorial representation of Fig. 4. Pictorial representation of 
equation [4] (sharing) equation [4] (duplication) 

On the other hand, if the shared sub-expression is a non-deterministic operation, 
then the outcome of the computation will not be correct. The following figures, 
[3]and|4] represent the expression in equation |4j The first one supports sharing 
and the second one converts sharing into duplication of shared expression. The 
rewriting of "?" produces the two only correct expressions in figure [Sj while the 
rewriting of "?" in figure |4] produces the two correct expressions along with two 
wrong ones. 

2.3 Evaluation strategy 

Evaluation of a logic programming goal is done by the construction of a proof 
in SLD-resolution. When a goal contains variables, then the system will provide 
the user with possible bindings for such variables that make the goal succeed. 
Evaluation in functional programming is done by the repeated rewriting of an 
expression until a normal form or an irreducible expression is reached which 
is not a normal form. The first case represents success if the normal form is a 
constructor term graph and all other cases represent failure of the computation. 

Evaluation of functional logic expressions is a mixture of both these ap- 
proaches. When we try to compute an expression that unifies with the left- 
hand-side of a deterministic rule, the expression will be rewritten to the right- 
hand-side of the same rule, similar to rewriting in functional programming. If the 
expression to be computed unifies with the left-hand-side of a non-deterministic 
rule, the expression can be rewritten to one of the right-hand-sides of the rule. 
Dealing with missing information is done by placing logical variables in the ex- 
pressions. The instantiation of logical variables is done by narrowing. Narrowing 
is the process of guessing a constructor term to substitute for a variable appear- 
ing in an operation-rooted expression. Thus, a logical variable can be rewritten 
to the non-deterministic choice operation with all guessed constructor terms 
becoming as arguments of such choice. Narrowing is comparable to unification 
and resolution in logic programming [12'13' and it is what essentially combines 
functional programming with logic programming. 



The evaluation strategy used to compute programs in the IS class is Needed 
Narrowing [7]- When the evaluation strategy encounters an uninstantiated vari- 
able, then it will either narrow the variable or residuate. Narrowing will allow 
expressions with uninstantiated variables to proceed in the computation process 
without suspension. Narrowing is complete and computes all solutions possi- 
ble. Residuation, on the other hand, delays and suspends the computation of 
sub-expressions containing the uninstantiated variable. The computation will 
continue only when such variable is instantiated while computing other sub- 
expressions. The absence of other sub-expressions that may compute values for 
such variable may cause residuation to suspend forever and, therefore, be unable 
to complete the computation. Needed narrowing uses narrowing to instantiate 
variables only when such variables are needed. The guidelines for needed nar- 
rowing depends on the definitional tree that contains the defined operation's 
rules. Non-deterministic operations belonging to the OIS class of term rewriting 
systems can be computed using the Inductively sequential Narrowing Strat- 
egy, INS [1;. INS is based on needed narrowing but lacks the ability to deal with 
sharing of sub-expressions. 

2.4 Previous approaches 

Computing functional logic programs with non-determinism and sharing can be 
tackled using different approaches. Backtracking is used to compute the alterna- 
tives of a non-deterministic operation one by one. Whenever an alternative fails 
in computing a value, the next alternative is tried. This approach is used in im- 
plementations that transforms functional logic programs into Prolog programs, 
like PACKS PCT , an implementation of Curry. 

loop — loop (5) 



(loop ? 1+2) (6) 

The computation of the expression appearing in equation [6] using backtrack- 
ing may never produce a normal form if the argument of "?" selected is the 
loop operation, while the value 3 can be produced using other approaches. Such 
behavior is referred to as the problem of incompleteness. 

f X = l+(2+(. . .+ (100 / x)...)) (7) 



Copying is an approach that is successful in tackling non-determinism and 
sharing. The concept is to reconstruct several copies of the whole expression for 
all the arguments of the non-deterministic operation "?" and to plug each argu- 
ment of the "?" in one of the copies. Consider the computation of the expression 
(f (0?1)) using copying, where f is defined by the rule in equation [t] (borrowed 
from [5]). The expressions (f 0) and (f 1) will be built to compute the alterna- 
tives of the choice. The expression (f 0), rewritten as l+(2+(. . .-|-(100 / 0). . .)), 



will fail immediately after the division by zero, (100 / 0), is encountered. All 
the effort in the construction of the expression (f 0) is wasted because failure is 
encountered at a very early stage of the computation [B] . Copying has been used 
in some experimental implementations |10I21) . 

3 Bubbling 

Bubbling is a graph transformation that preserves the completeness of non- 
deterministic operations without the need to construct unnecessary copies for 
the whole original graph. The transformation depends on finding a dominator 
of a needed choice and then "bubbling" the choice up to take the place of its 
dominator. The choice will become the immediate parent of the dominator and 
several copies of all the nodes that fall between the choice and its dominator, 
the Ancestral Path, will be made. All the edge links between the nodes that are 
part of the ancestral path and other nodes of the graph will be preserved. 

We introduce some properties that hold for the term graph rewriting system 
of interest and some functions that will help in the bubbling process. 

[Acyclic structure] V x, y G Ng. If x is reachable from y, then y cannot be 
reachable from x. That is, no cycles are allowed in g. 

The acyclic structure of the graph does not limit the capabilities of TRS. We 
recall that admissible graphs contain no cycles among the defined operations 
|15I14| . We use this property to ensure efficient execution of the function Path- 
ToRoot that collects all the paths that connects a certain node of the graph to 
the root. 

[Parent] Parent : Ng x Ng — )■ B. A node p is a parent of a node x if p is 
related to x through the edge function Eg. 

BackPointers: Bg-. Ng — > 2^' is the Back pointers function that maps a node 
x of a graph g to the set of the parent nodes of x. 

Path: 2^' . A path is a sequence of nodes connected to each other through 
the BackPointers function starting from a node x to Rootg. An example of a 
path is nin2 ■ ■ ■ Uk, where ni is the parent of x, n,; is the parent of n.i^i V i, 1 
< i < k, and n^, is Rootg. 

PathToRoot: Ng 2"^^^ is a function that takes a node x and returns the 
set of all paths that connect x to Rootg. 

[Root] V x e Ng \ {Rootg}, Rootg is a dominator of x. 

AncestralPath: 

22 " ^ X Ng is a function that takes all the paths con- 
necting a node x to Rootg and returns a node a, a dominator, and the set of 
nodes, AP, that forms the backbone that connects x to the dominator a. 

(Fact X + Fibo X) where X = ( 2 ? 3 ) (8) 

Figure[5]is a term graph representation of the expression in equation[8] where 
Fact and Fibo represent the unary defined operations factorial and fibonacci 
respectively. Figure [6] represents a bubbling transformation of the term graph 
represented in Figure [5] where the root of the graph, the node labeled +, is 




2 3 



Fig. 5. Pictorial representation 
of the expression in equation |8] 




2 3 

Fig. 6. Bubbling transforma- 
tion of the expression in equa- 
tion [8] 



the dominator of the choice operator and the ancestral path consists of the 
nodes labeled Fact, Fibo and +. The choice operator becomes the root of 
the transformed graph and all necessary updates of the graph components are 
incorporated in the transformed graph. Details of all the updates are to follow. 

A dominator of a node x is a node that appears in all the paths that connect 
the node x to the root of the graph. Therefore, the root of the graph is a dom- 
inator for all nodes of the graph other than itself. All the nodes that connect 
a node x to its dominator are part of the ancestral path. Our goal is to find 
a "least dominator" for a node. By least, we mean that the dominator will be 
the nearest to the node in question than all other dominators to minimize the 
number of nodes that are part of the ancestral path. We will see the benefits of 
such approach after defining the bubbling function. 

Bubbling: GRAPH xNg x Ng x g 

Bubbling {{Ng, Lg, Eg, ROOtg), X, a, AP) = {Ng^, Lg^, Eg^, ROOtgJ 

The bubbling function takes a graph g, a source node x, a dominator node a 
and the ancestral path AP that connects x to a. Bubbling transforms the original 
graph by copying all the nodes that are part of AP and "bubbles" the node x up 
in the graph to take the place of node a. All the edge links must be maintained 
as mentioned in the definition of Edge links below {Eg^ ) . The root of the graph 
may change when the dominator is Rootg. 

Having several copies of the nodes that are part of AP motivates the need 
to find a dominator that minimizes such set. Figure [7] represents a pictorial 
representation of the expression in equation [9j The transformation of the graph 
by bubbling with the dominator node a, represented in Figure [9j copies less 
nodes than bubbling with the root as the dominator, represented in figure [8j 



Please note that the copying approach discussed in section 2.4 is a special case 
of bubbling where the dominator is the root of the graph. 

( ( (3 / X) + (X X 2) ) - 4) where X = ( ? 1 ) (9) 



We describe here the transformations of the different components of the orig- 
inal graph after a call to the function bubbling: 

arity(x) 

Ng^ = {Ng \ AP ) UAi where A, ^ |J n,V n € AP A iVg n A, = 



Fig. 7. Pictorial representation of equation |9] 



Lg^{n) = Lg{n) if n ^ AP 

Lg^{ni) = Lg{n) if n G AP A < i < arity(x) 



Eg{n,pos) if n ^ AP A n 7^ x 



Eg^{n,pos) = ^ X 



if -Eg(n, pos) = a 

< pos < arity(x) A n = x 



rui if n, m e AP A Eg{n, pos) = m 

m if n e AP V m ^ AP A m 7^ x A i?g(n, pos) = ni 

p if n e AP A Eg{ii, pos) = x A £^g(x, i) = p 



Roota 



J Rootg if Rootg ^ a 
1 a; if Rootg = a 





Fig. 8. Graph Bubbling with Fig. 9. Graph Bubbling with 
the root as dominator node a as dominator 



4 Implementation Details 



In this section we describe the details of the current stage of the implementation 
of the evaluation strategy used to compute functional logic language expressions 
and the bubbling transformation needed to model non-determinism in such ex- 
pressions. 

4.1 Symbols 

Symbols represent elements of both U and X. Each symbol has a name, an 
operator designation and a value. The name is represented as a string, while 
operator designation and value as integer values. The main operator designation 
represented are defined operations, data constructors and variables. We add also 
two special cases of operator designation: numbers and fail. Numbers are a special 
case of data constructors separated from their main operator designation to 
speed up computations. Values are only associated with symbols of the operator 
designation number and are represented as integers. The fail symbol is also added 
to represent the inability to compute a (head) normal form of the expression. 
All predefined symbols are kept in an array of distinct symbols to ensure no data 
constructor or defined operation has the same name. 



4.2 Expressions 

An expression is represented as a graph. We will represent the graph in a table. 
Each expression entry is represented by the following: (1) A root that represents 
the symbol of the expression. (2) An array of arguments that represent the 
positions of the arguments in the terms table. (3) An array of back pointers that 
contains the positions of the immediate parents of the expression in the table. 

(4) Minimum and maximum depth of the expression in the expressions table 
represented by how far an expression is from the root expression of the table. 

(5) A tag that represents whether a normal form of this expression has been 
reached or not. 



Symbol Name | Operator 

Arguments III 
Back pointers III 

Depth Minimum | Ma^imur 



Tag 



Symbol | loop | operation | 
Arguments 

Backpointers I " I 

Depth 1^1^ 

y^g I Not Normal Form 



Fig. 10. Pictorial representa- 
tion of a typical term entry in 
the expressions table 



Fig. 11. Pictorial representa- 
tion of the node labeled "loop" 
in the expression in equation |6] 



4.3 Parser 



The first stage of computing an expression is to parse the expression needing 
evaluation by checking whether it is well-formed. The duty of the parser is to 
build a term graph and populate the expression table mentioned in section |4.2[ 
Expressions are built as directed acyclic graphs. Sharing of expressions is done 
through variables. 



4.4 Revirrite rules 

Rewrite rules are coded using definitional trees. The definitional tree is built 
in this implementation manually. All the rewrite rules are coded in a single 
function and the program will branch to the appropriate rewrite rule according 
to the defined operation needing evaluation. When a defined operation t needs 
evaluation, the steps in Figure [l2| will take place to decide what is required to 
compute t. 



Switch (needed position n) 
case n is FAIL 

rewrite as FAIL 
case n is OPERATION 

step on n 
case n is CONS or NUMBER 
if n matches LEAF 

rewrite to right-hand-side 
else if n matches INNER BRANCH 

Continue on another needed position 

else 

rewrite as FAIL 
End if 
End Switch 



Fig. 12. function to match a needed position using Definitional Trees 



4.5 Computations 

The computation of an expression in the virtual machine is done by rewriting it 
to an expression in head normal form or normal form using the rewrite rules. 

The evaluation of an expression to an expression in head normal form is 
done by rewriting operation-rooted expressions using rewrite rules to a constructor- 
rooted expression. All variables and constructor-rooted expressions are already 



in head normal form as discussed earlier in section [2T| The initial step taken 
to compute head normal form for an expression is done by inspecting the root 
of the expression to be evaluated. Evaluating an expression to be in normal 



step (term t, mode m) 

if t is FAIL or NUMBER 
exit 

else if t is CONS 

if m is NORMAL FORM 

collect all OPERS ops part of t 
if any ops is FAIL 
rewrite as FAIL 
exit 
End If 

step on all ops 
exit 

else if m is HEAD NORMAL FORM 

exit 
End if 
else if t is OPERATION 

goto rewrite rule of t 
execute rewrite rule outcome 
End if 
End Step 

Fig. 13. Procedure to perform a "step" on a term 



form is done through evaluating the expression to head normal form and then 
checking that all of the expressions arguments are also in normal form. This 
will guarantee that the expression and all its arguments are constructor-rooted 
expressions containing no operation-rooted expressions. The expression "cons(2, 
nil)" is in normal form, while the expression "cons((l + 1), nil)" is in head 
normal form but not in normal form. 

The evaluation strategy will only inspect the needed arguments of the de- 
fined operation. A single rewriting step is executed on the arguments needing 
further evaluation or a rewriting of the defined operation will be done. A single 
computation step guarantees that the arguments are "touched" only once during 
a single round of evaluation. On the other hand, full evaluation of the arguments 
to head normal form resembles the backtracking approach discussed in section 
|2.4[ which is operationally incomplete. An example of a round of single "rewrit- 
ing step" is: (Fact 5 -f Fact 6) — >■ ( (Fact 4 x 5) -|- (Fact 5x6)). Several rounds 
will be conducted until a head normal form for the expression is reached. 

The process of evaluating an expression to normal form will start by first 
evaluating the expression to head normal form, i.e., constructor-rooted expres- 
sion and then evaluating all the arguments of the constructor-rooted expression 
to normal form. If any of the arguments of the expression is of type "fail", 
failure will be declared and no normal form is obtained from such expression. 



4.6 Non-determinism 



Non-determinism represented by the choice operator is the main issue tackled 
by this implementation. When a choice is needed the steps in figure [14] will be 
performed. 



CodeChoice (term t) 

Remove all FAIL from arguments (t) 
if all arguments (t) are OPERATIONS 
step on arguments (t) 
exit 

else if any arguments (t) is in HEAD NORMAL FORM 
if arity(t) = 

rewrite t as FAIL 
else if arity(t) = 1 

rewrite t as argument (t) 
else if arity(t) > 1 
P = PathToRoot(t) 
dominator, AP = AncestralPath(P) 
Bubble (t, dominator, AP) 
exit 
End if 
End if 
End CodeChoice 

Fig. 14. Procedure to perform a "rewrite step" on a choice term 



The calculation of the "least dominator" and ancestral path AP of the choice 
node is done by finding the farthest node from the root of the graph that is a 
dominator of the choice node. Finding the "least dominator" is done with the aid 
of some heuristic information about the minimum and maximum depth range of 
each node in the graph. The minimum depth represents the shortest distance this 
node can be from the root of the graph, while the maximum depth represents 
the farthest distance this node can be from the root of the graph. The depth 
of a node can change by adding a parent to such node or by a change in the 
depth of a current parent. To minimize the effect of updating the minimum and 
maximum depths of a node, the minimum depth will be decreased in case the 
new minimum depth is smaller than the current minimum depth. The maximum 
depth is updated if the new maximum depth is greater than the old maximum 
depth. Deleting a parent may cause a change in the minimum and maximum 
depths of the node but the virtual machine will not update the depths of the 
node because of the high cost incurred from such update. This will only affect 
the efficiency of finding the "least dominator" of a node. 



5 Future work 



The current implementation can successfully compute normal forms of expres- 
sions containing deterministic and non-deterministic operations. The evaluation 
strategy used keeps making single computation steps on the root of the expres- 
sion until a normal form is reached. A step on a deterministic operation either 
rewrites the expression when all its needed arguments are in normal form or 
performs a step on each needed argument not in normal form. 
The current implementation lacks an implementation of narrowing or logical 
variables. The presence of an efficient implementation of narrowing is extremely 
important. The essence of functional logic computations is to incorporate a mech- 
anism for dealing with missing and partial information, which is satisfied by 
logical variables. 

The long-term goal of the implementation is exploitation of parallelism. Accord- 
ing to Gupta et al. declarative and logic programming is seen to be well suited 
for parallelism |16| . Exploitation of and-parallelism, or-parallelism or both is 
possible. And-parallelism can be exploited by collecting and executing several 
needed expressions at the same time. However, synchronization of expressions 
may be needed to express dependencies based on sharing. Or-parallelism can be 
exploited by trying different arguments of the choice simultaneously. 
Further tuning of the evaluation strategy is needed. The evaluation strategy 
adopted in the current implementation exhibits a naive implementation of breadth- 
first evaluation and needs additional improvements. The automatic generation of 
code for definitional trees is a desirable feature to be implemented in the future. 
Finding the "least dominator" needs an efficient implementation. The literature 
has some good results for "offline" graph settings where queries can be answered 
in constant time, but no current efficient algorithm for a dynamic graph is yet 
available. 

6 Conclusion 

We introduced an implementation of bubbling, a mechanism that tackles non- 
determinism correctly and efficiently. Backtracking is incomplete and cannot 
model non-determinism. On the other hand. Copying is a special case of bubbling 
where the root is always considered the dominator. This approach is complete 
but lacks efficiency due the reconstruction of nodes unnecessarily if failure is 
detected in one of the alternatives of a choice in an early stages. 
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